The increasing reliance upon computer systems to collect, process, and analyze data has led to the continuous improvement of the system assembly process and associated hardware. With the improvements in speed and density of integrated circuits, the cost and complexities of designing and testing these integrated circuits has dramatically increased. Currently, large complex industrial integrated circuit testers (commonly referred to in the industry as “Automated Test Equipment” or “ATE”) perform complex testing of integrated circuit devices, such as integrated circuits, printed circuit boards (PCBs), multi-chip modules (MCMs), System-on-Chip (SOC) devices, printed circuit assemblies (PCAs), etc. The tests that must be performed may include, among others, in-circuit test (ICT), functional test, and structural test, and are designed to verify proper structural, operational, and functional performance of the device under test (DUT).
An example of an automated test is the performance of an in-circuit test. In-circuit testing, which verifies the proper electrical connections of the components on the printed circuit board (PCB), is typically performed using a bed-of-nails fixture or robotic flying-prober (a set of probes that may be programmably moved). The bed-of-nails fixture/robotic flying-prober probes nodes of the device under test, applies a set of stimuli, and receives measurement responses. An analyzer processes the measurement responses to determine whether the test passed or failed.
A typical in-circuit test will cover many thousands of devices, including resistors, capacitors, diodes, transistors, inductors, etc. Tests are typically passed to the tester via some type of user interface. Typically, the user interface allows a technician to enter various configurations and parameters for each type of device to automatically generate tests for devices of that type. However, for various reasons, it is often the case that a fairly significant percentage (e.g., 20%) of the automatically generated tests are faulty in that when executed on a known good device under test, the test is unable to determine the status of the device or component under test. Clearly, for devices under test that include thousands of components, this results in a large number of tests that must be manually repaired. Expert technicians typically know how to repair a faulty test. However, with such a large number of faulty tests to repair, a large (and therefore, very costly) amount of time may be spent in test debug and optimization rather than in actual testing of the device itself. The time spent in debug is also dependent on the amount of knowledge and experience of the test engineer.
It would therefore be desirable to capture the knowledge of experienced test engineers and formulate it into a format that s reusable by automated test systems. More generally, it would be desirable to develop a method and framework for binding complex actions into rules and rule sets associated with devices under test.